home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
IRIX Base Documentation 1998 November
/
IRIX 6.5.2 Base Documentation November 1998.img
/
usr
/
share
/
catman
/
u_man
/
cat1
/
X11
/
xkbevd.z
/
xkbevd
Wrap
Text File
|
1998-10-30
|
6KB
|
133 lines
XXXXKKKKBBBBCCCCOOOOMMMMPPPP((((1111)))) XXXX VVVVeeeerrrrssssiiiioooonnnn 11111111 ((((RRRReeeelllleeeeaaaasssseeee 6666)))) XXXXKKKKBBBBCCCCOOOOMMMMPPPP((((1111))))
NNNNAAAAMMMMEEEE
xkbevd - XKB event daemon
SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
xxxxkkkkbbbbeeeevvvvdddd [ options ]
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
This command is very raw and is therefore only partially
implemented; we present it here as a rough prototype for
developers, not as a general purpose tool for end users.
Something like this might make a suitable replacement for
xev; I'm not signing up, mind you, but it's an interesting
idea.
The _x_k_b_e_v_d event daemon listens for specified XKB events and
executes requested commands if they occur. The
configuration file consists of a list of event
specification/action pairs and/or variable definitions.
An event specification consists of a short XKB event name
followed by a string or identifier which serves as a
qualifier in parentheses; empty parentesis indicate no
qualification and serve to specify the default command which
is applied to events which do not match any of the other
specifications. The interpretation of the qualifier depends
on the type of the event: Bell events match using the name
of the bell, message events match on the contents of the
message string and slow key events accept any of _p_r_e_s_s,
_r_e_l_e_a_s_e, _a_c_c_e_p_t, or _r_e_j_e_c_t. No other events are currently
recognized.
An action consists of an optional keyword followed by an
optional string argument. Currently, _x_k_b_e_v recognizes the
actions: _n_o_n_e, _i_g_n_o_r_e, _e_c_h_o, _p_r_i_n_t_E_v_e_n_t, _s_o_u_n_d, and _s_h_e_l_l.
If the action is not specified, the string is taken as the
name of a sound file to be played unless it begins with an
exclamation point, in which case it is taken as a shell
command.
Variable definitions in the argument string are expanded
with fields from the event in question before the argument
string is passed to the action processor. The general
syntax for a variable is either $_c_P _o_r $(_s_t_r), _w_h_e_r_e _c _i_s _a
_s_i_n_g_l_e _c_h_a_r_a_c_t_e_r _a_n_d _s_t_r _i_s _a _s_t_r_i_n_g _o_f _a_r_b_i_t_r_a_r_y _l_e_n_g_t_h.
_A_l_l _p_a_r_a_m_e_t_e_r_s _h_a_v_e _b_o_t_h _s_i_n_g_l_e-_c_h_a_r_a_c_t_e_r _a_n_d _l_o_n_g _n_a_m_e_s.
The list of recognized parameters varies from event to event
and is too long to list here right now. This is a
developer release anyway, so you can be expected to look at
the source code (evargs.c is of particular interest).
The _i_g_n_o_r_e, _e_c_h_o, _p_r_i_n_t_E_v_e_n_t, _s_o_u_n_d,and _s_h_e_l_l actions do
Page 1 (printed 4/30/98)
XXXXKKKKBBBBCCCCOOOOMMMMPPPP((((1111)))) XXXX VVVVeeeerrrrssssiiiioooonnnn 11111111 ((((RRRReeeelllleeeeaaaasssseeee 6666)))) XXXXKKKKBBBBCCCCOOOOMMMMPPPP((((1111))))
what you would expect commands named _i_g_n_o_r_e, _e_c_h_o,
_p_r_i_n_t_E_v_e_n_t, _s_o_u_n_d, and _s_h_e_l_l to do, except that the sound
command has only been implemented and tested for SGI
machines. It launches an external program right now, so it
should be pretty easy to adapt, especially if you like audio
cues that arrive about a half-second after you expect them.
The only currently recognized variables are _s_o_u_n_d_D_i_r_e_c_t_o_r_y
and _s_o_u_n_d_C_m_d. I'm sure you can figure out what they do.
OOOOPPPPTTTTIIIIOOOONNNNSSSS
----hhhheeeellllpppp Prints a usage message that is far more up-to-date
than anything in this man page.
----ccccffffgggg _f_i_l_e
Specifies the configuration file to read. If no
configuration file is specified, _x_k_b_e_v_d looks for
~/.xkb/xkbevd.cf and $(LIBDIR)/xkb/xkbevd.cf in that
order.
----sssscccc _c_m_d Specifies the command used to play sounds.
----ssssdddd _d_i_r_e_c_t_o_r_y
Specifies a top-level directory for sound files.
----ddddiiiissssppppllllaaaayyyy _d_i_s_p_l_a_y
Specifies the display to use. If not present,
_x_k_b_e_v_d uses $DISPLAY.
----bbbbgggg Tells _x_k_b_e_v_d to fork itself (and run in the
background).
----ssssyyyynnnncccchhhh Forces synchronization of all X requests. Slow.
----vvvv Print more information, including debugging
messages. Multiple specifications of -_v cause more
output, to a point.
SSSSEEEEEEEE AAAALLLLSSSSOOOO
X(1)
CCCCOOOOPPPPYYYYRRRRIIIIGGGGHHHHTTTT
Copyright 1995, Silicon Graphics Computer Systems and X
Consortium, Inc.
See _X(_1) for a full statement of rights and permissions.
AAAAUUUUTTTTHHHHOOOORRRR
Erik Fortune, Silicon Graphics
Page 2 (printed 4/30/98)